Problem:
Ładowanie rozpoczęło się w weekend a w poniedziałek rano stwierdziliśmy, że cluster wciąż działa. Ładowanie, które rozpoczęło się w niedzielę rano, trwało ponad 24h i w poniedziałek rano ładowanie wciąż było w trakcie. W sumie ładowanie powinno trwać 3h, trwało ponad 21h dłużej i nie zakończyło się sukcesem. Pociągnęło to za sobą duże koszty i nasunęło dwa pytania: co się stało, dlaczego cluster działa tak długo? Co zrobić, żeby to się więcej nie powtórzyło.
Rozwiązanie (a raczej przyczyna)
Spojrzenie w szczegóły ładowania pokazały, że był jeden notebook, gdzie ładowanie trwało ponad 21h i wciąż trwało. Jeżeli właśnie pomyślałeś, że to duplikaty to masz rację. Dane zostały zwielokrotnione. Dla niektórych rekordów z tabeli źródłowej było 32 768 rekordów. Nie spowodowało to wywrócenia procesu i błędu wskazującego na nie wystarczającą pamięć (out of memory exception). Ładowanie trwało ale trzeba było je przerwać, nie chcieliśmy go kontynułować, gdyż nie zawierało poprawnych danych.
Dobrze wiemy już co się stało, w takim razie jak przeciwdziałać takim sytuacjom w przyszłości?
Duplikaty
Najpierw zidentyfikujmy skąd wzięły się duplikaty. Po dochodzeniu okazało się, że system źródłowy nagle zaczął udostępniać zbyt dużo danych. Widoki udostępniające dane nie przewidywały tego, że mogą pojawić się duplikaty.
W kilku miejscach zostały dodany distinct, żeby ograniczyć możliwość pojawienia się duplikatów. To taki szybki hot fix, gdyby znowu system źródłowy zaczął znowu udostępniać niepoprawne dane.
W tym przypadku wyeliminowanie duplikatów było proste, gdyż cały wiersz był zduplikowany. Co jednak gdy duplikaty pojawią się na kluczy biznesowym a pozostałe kolumny będą różne?
Także zgadzam się z Tobą, jeżeli myślisz, że nie rozwiązaliśmy problemu, bo nie dotarliśmy do źródła, ale to nie miejsce na tą dyskusje.
Tylko tutaj mamy zabezpieczenie przed ponownym pojawieniem się duplikatów z jednego systemu źródłowego. Co jeżeli duplikaty zaczną pojawiać się w innym miejscu? Nie chcemy wszędzie dodawać polecenia distinct szczególnie, że przy duplikatach tylko na kluczy on nie rozwiąże problemu.
Zbyt długo działający cluster
Databricks dodał niezwykle ciekawą i przydatną funkcję, z której można skorzystać, żeby zatrzymać zbyt długo działający cluster:
Duration and streaming backlog thresholds
Ta opcja jest obecnie (22.09.2025) w preview, ale na tyle dobrze działa, że możesz rozważyć jej zastosowanie w środowisku produkcyjnym.
Umożliwia ona ustawienie po jakim czasie wysłana zostanie notyfikacja, że job działa zbyt długo, wtedy będzie można w miarę możliwości samemu zareagować i zdecydować co robić z ładowaniem.
W 'Timeout threshold' ustawiasz po jakim czasie Databricks zacznie procedurę anulowania wykonania joba. Działa to na tyle sprytnie, że gdy masz "master joba', który uruchamia joby zależne, wtedy master tak jak i podrzędne joby zostaną anulowane. Choć można niezależnie ustawić Timeout na każdym z jobów z drzewa wykonania, jeżeli chcesz mieć nad tym aż tak dużą kontrolę, jeżeli nie wtedy wystarczy ustawić w głównym zarządzającym jobie ile czasu ma trwać.
Podsumowanie
Ciekawym rozwiązaniem jest zarządzanie długością wykonania job'a. Wtedy nawet przy innym problemie z długo działającym clustrem można:
- Obsłużyć powiadomienie, że job długo działa i obsłużyć problem w czasie rzeczywistym
- Gdy nie ma nikogo z supportu w okolicy, wtedy po przekroczeniu czasu wykonania można anulować joba i zatrzymać wszystkie zależne od niego joby. Następnie, gdy udało się naprawić job'a można wznowić ładowanie od miejsca gdzie skończył. To też jest super funkcjonalność.